一位後端工程師花了半個週末，把 GitHub、Sentry 和內部 Confluence 的 MCP server 手動接進 Codex——配置文件、認證流程、指令模板，一條一條寫進 ~/.codex/config.toml。這些 Power User 一直知道可以這樣做。
2026 年 3 月 27 日，OpenAI 把同樣的事情做成了一鍵安裝。
那位工程師在推特上留言：「我剛浪費了一個週末。」
但他沒說的那一半是：他為 Claude Code 做了同樣的事，已經是四個月前的事了。
最後一家追上來了，但這不是重點
OpenAI Codex Plugin Marketplace 正式上線，一口氣提供 GitHub、Gmail、Slack、Figma、Notion、Cloudflare、Vercel 等 20 多款插件，支援 app、CLI 與 VS Code 一鍵安裝。
這件事的表面新聞很清楚：Codex 終於追上了 Claude Code 約五個月前就有的 plugin 功能。
但追平了之後，故事才真的開始。
當三大 AI 程式助理——Codex、Claude Code、Gemini CLI——都採用了相同的技術架構（MCP + Skills + Apps），功能層面的壁壘消失了大半。選哪個都能連 GitHub、都能裝自訂 Skills、都能讓 IT 設置治理政策。Ars Technica 把這個時刻定性為「OpenAI officially takes Codex beyond coding」——不只是寫程式的工具，而是知識工作平台的入口。
問題是，當入口長得越來越像，你走進去之後走的路，差距才真的開始。
Plugin 是什麼？三層打包，不是一個功能
理解這場競爭，先要搞清楚 Plugin 到底是什麼。
根據 OpenAI 官方文件，一個 Codex Plugin 是三層東西的捆包：
- Skills：預先定義好的任務指令，告訴 AI「執行這類工作時按照這個流程走」。舉個例子：一個 PR Review Skill 可能包含「先檢查測試覆蓋率、再看命名規範、最後輸出建議清單」。
- Apps：第三方服務整合，讓 AI 可以直接讀寫 GitHub Issue、Slack 頻道、Google Drive 文件。
- MCP Servers：Anthropic 於 2024 年 11 月提出、OpenAI 於 2025 年 3 月正式採用的開放標準，讓 AI 工具透過統一協定與外部系統溝通。
以前 Power User 可以自己把這三層手動組起來，現在 Plugin 是把它打包成一鍵安裝。技術上沒有突破，但標準化打包讓它從「個人設定」變成「團隊共享設定」——這是真正的改變。
企業端還加了一層：IT 管理員可以用 JSON Policy 的三種狀態控制哪些 Plugin 員工能裝：INSTALLED_BY_DEFAULT（預設安裝）、AVAILABLE（員工可選裝）、NOT_AVAILABLE（不開放）。Forrester 分析師形容這是「從臨時使用轉為受管理的基礎建設」的關鍵一步。
三大平台現在的真實差距
功能趨同不代表沒有差距，而是差距的性質變了。
Codex 的優勢在企業治理。JSON Policy 機制是三大中最成熟的集中管控工具，對需要合規控管的大型機構有實際吸引力。缺點是起步最晚（plugin 生態晚了約五個月）、定價較高（起步 $200/月，是 Claude Code Max 方案的兩倍）。
Claude Code 的優勢在生態成熟度。早約五個月推出同類功能，Skills 生態積累較深，且目前報導指出 sub-agent 能力（讓 AI 可以拆解任務並協調多個子任務同步進行）是 OpenAI 目前尚未完整跟進的維度。$100/月 定價對個人與中小團隊也更友善。
Gemini CLI 的優勢在 Google Workspace 整合。如果你的團隊主要工作在 Google Docs、Sheets、Meet 生態裡，Gemini 的深度整合有天然優勢。但整體 plugin 生態廣度目前最淺。
這不是一張跑分表，而是一個框架問題：你的團隊主要的工作環境在哪裡？
你以為在選工具，實際上在選三年後的工作慣性
MCP 是開放標準。技術上，換平台比以前容易多了——一套 MCP server 理論上可以跨平台複用。
但這會讓你低估了真正的轉換成本。
技術整合可以搬，有三樣東西搬不走：
第一是你的 Skills 包積累。你的團隊在一個平台上慢慢寫出的 Skills——PR review 流程、onboarding checklist、週報生成模板——每一個都是一點學習成本結晶出來的東西。它們不是不能移植，但沒人有時間移植。
第二是 IT 治理設定。你的 IT 部門在 JSON Policy 裡設定的 Plugin 白名單、憑證管理規則，是一套配合公司合規需求慢慢調出來的東西。換平台等於重新協商這整套配置。
第三是團隊的工作習慣。習慣用 @github 把 Issue 拉進對話的工程師，不會無縫過渡到另一個平台的類似功能——即使技術上一模一樣，肌肉記憶還是要重建。
這個成本在你剛開始用的第一年幾乎是隱形的。在第三年，它是真正的壁壘。
現在問三個問題，而不是等下一份跑分報告
Plugin 架構上線之後，功能追平的消息會一個接一個出現。Codex 補上 sub-agent、Claude Code 強化 JSON Policy、Gemini CLI 拓展 Marketplace——這個節奏短期內不會停。
等跑分等不到「答案」，因為答案在你自己的工作環境裡。
現在值得問的三個問題是：
一、你的團隊主要工作環境在哪裡？ 重度 Google Workspace、以 GitHub/Slack 為中心、還是需要強合規控管？這決定了哪個平台的生態整合對你最有摩擦、哪個最順。
二、你的團隊已經在哪個平台上積累了什麼？ 如果還沒有任何 Skills 包或治理設定，現在才是真正自由選擇的時機。如果已有積累，算清楚移轉成本才有意義。
三、sub-agent 能力對你的工作流程重不重要？ 目前報導指出這仍是 Claude Code 未被追上的差距（此點尚待更多公開測試確認）。如果你的應用場景需要 AI 協調複雜的多步任務，這是一個值得追蹤的維度。
三大平台在功能收斂的路上越走越近。但生態選擇的視窗，就在這段「都能用、都差不多」的時間裡。
你現在裝的 Skills、IT 設的政策、工程師養成的指令習慣——在你意識到它們之前，轉換成本已經開始累積了。